Generic download and upload functionality in a client/server web application architecture

ABSTRACT

The present invention relates generally to client-server architectures for allowing generic upload and download functionality between a web application at a server and a client. One exemplary method includes sending a download/upload request to a web application at the server, where the download/upload request specifies at least one file to download/upload; receiving a transmission from the server; parsing the transmission to identify a download/upload command and an associated download/upload manifest, where the download/upload manifest includes executable code that, when executed on the client, will perform the download/upload of the at least one file.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation-in-part application of U.S.application Ser. No. 11/195,284, filed Aug. 2, 2005, and entitled“Client/Server Web Application Architectures for Offline Usage, DataStructures, and Related Methods,” which application is incorporatedherein by reference in its entirety.

BACKGROUND OF THE INVENTION

1. The Field of the Invention

The present invention relates to various client/server web applicationarchitectures that provide enhanced features for web applicationsrunning on a client.

2. The Relevant Technology

Web applications are accessed by millions of people every day over theInternet. Because of the increased simplicity of developing webapplications, web applications have been developed to perform variousfunctions such as providing news content, electronic messaging, audioand visual applications, financial applications, and so on. Typically, auser accesses a web application using a browser application on a clientcomputer. The browser application sends requests to the server hosting aweb application to return the desired web document code for display bythe browser application. Because a server can respond to thousands ofrequests almost simultaneously, thousands of users can simultaneouslyuse the web application hosted by the server.

However, because a network can be handling thousands of requests at anygiven time, users can experience latency in receiving data from theserver. Attempts have been made to decrease the latency in networkresponse. One method for reducing latency is to cache or prefetch webdocuments in a browser cache at the client. However, local caching hashistorically been most efficient when the web documents are limited totext and graphic content. Furthermore, a browser cache is not secure andthus, caching user-identifiable information such as addressauto-complete lists or electronic messages has been discouraged. Anothermethod for attempting to reduce latency in web application operation isto place one or more local proxy servers between the server and theclient. A local proxy server stores web document code in cache andreturns the web document code to a client upon the client's request.However, again, a local proxy server is most efficient for cachingstatic web pages containing mostly text and images.

Where web applications are increasingly relying on dynamic web contentthat usually resides at the server, a client must still communicate witha server to access the dynamic web content. Likewise, a local proxyserver must still make a request to the server for this informationbefore the local proxy server can return a properly generated webdocument to the client. When information from the server has beenrequired, e.g., from a database stored on the server, access toinformation on the server has typically been accomplished by causing aweb application to initiate a common gateway interface application atthe server. Alternatively, a web application may include script, such asa Java servlet. In these situations where the web application mustaccess information at the server, proper operation of web documents on aclient relies on a working network connection between the client andserver. Even where a local proxy server exists, when the local proxyserver becomes disconnected with the server, it is unable to adequatelyfunction to provide a working web site.

Further, in many cases when operating a web application, it is desirableto be able to access local data pertaining to the same digital contentthat the web application is configured to handle. For example, for a webapplication that manages digital photo processing, a user would find itbeneficial to use the same functionality on digital photos storedlocally at the user's computer. However, the user is generally requiredto upload digital photos to be stored remotely at the server that hoststhe web application in order to be able to view and manipulate thedigital photos within the web application.

BRIEF SUMMARY OF THE INVENTION

The present invention relates to client/server web applicationarchitecture that provides a number of additional features that have notbeen available heretofore. The client/server web applicationarchitecture can operate with a traditional server-client network wherea web application is hosted by a server and accessible by the client.Additional features include, but are not limited to, 1) ability of theclient to respond to server-side control commands; 2) caching webapplications, executable code, web documents, security code, and/orremote files for online and offline usage; 3) allowing access by a webapplication to local files stored on the client; 4) providing varioussecurity measures between server and client interactions and alsoproviding security measures within the client itself while offline; 5)ability to run a web application on the client even when offline whilecontinuing to have access to substantially all of the functionality ofthe web application; 6) synchronizing local files with remote files; 7)ability of the client to respond to server-side download commands orupload commands that enable the client to download files to the clientfrom the server or to upload files to the server from the client; and 8)various other background agents for providing additional functionalitythat can occur independently of a web application.

Using some or all of these features, the present invention improves webapplication performance while running on the client. In one embodiment,some of these features are provided by a local web engine on the clientthat interacts with a browser application and browser cache operating onthe client. The local web engine also interacts with an engine cachethat can store web applications, executable code, web documents,security code, remote files, and the like. The present inventionseamlessly transitions between remote transactions and localtransactions without the user being aware of such occurrences. Further,remote files can be accessible locally at the client, and local filescan be accessible through a web application. By being able to maintainenough of the web application and/or remote files on the client alongwith instructions on how to treat certain offline scenarios, the presentinvention allows a user to operate a web application offline. Thepresent invention then seamlessly synchronizes the remote files storedlocally with remote files stored at the server. Thus, the webapplication is able to essentially run like a client application withaccess to the client's local files as well as remote files.

The present invention also includes data structures and computerreadable mediums for use in performing the above and other functions.

These and other features of the present invention will become more fullyapparent from the following description and appended claims, or may belearned by the practice of the invention as set forth hereinafter.

BRIEF DESCRIPTION OF THE DRAWINGS

To further clarify the above and other features of the presentinvention, a more particular description of the invention will berendered by reference to specific embodiments thereof which areillustrated in the appended drawings. It is appreciated that thesedrawings depict only typical embodiments of the invention and aretherefore not to be considered limiting of its scope. The invention willbe described and explained with additional specificity and detailthrough the use of the accompanying drawings in which:

FIG. 1A illustrates an exemplary embodiment of a server/clientarchitecture for offline usage;

FIG. 1B illustrates another exemplary embodiment of a server/clientarchitecture for offline usage;

FIG. 2 illustrates an exemplary method for caching application code;

FIG. 3 illustrates an exemplary method for caching web documents andsecurity code;

FIG. 4 illustrates an exemplary transmission data structure forincluding control commands and manifest code;

FIG. 5 illustrates an exemplary method for allowing web applications toaccess local files at the client;

FIG. 6 illustrates an exemplary method for an offline usage scenario;

FIG. 7 illustrates an exemplary method, from a client perspective, fordownloading files to the client from a server;

FIG. 8 illustrates an exemplary method, from a server perspective, fordownloading files from the server to a client;

FIG. 9 illustrates an exemplary method, from a client perspective, foruploading files from the client to a server; and

FIG. 10 illustrates an exemplary method, from a server perspective, foruploading files to the server from a client.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

The present invention relates to providing improved functionalities forInternet-based client/server applications, or any application in which aclient communicates with a server via a remote connection, whether theconnection is wired or wireless. With reference to FIG. 1A, an exemplarynetwork system 100A includes a server 102 communicating with one or moreclients 104. The server 102 includes a web application 106 and remotefiles/registry 108 that cooperate to provide the functionalities of awebsite hosted by server 102. As used herein, a “web application” or“website” refers generally to an entire application code. A webapplication typically consists of multiple web documents or web pages.Thus, a “web document” or “web page” refers to the amount of coderequired to generate only a particular web document of a webapplication. In many cases, the web application 106 is configured to beviewed through a browser application 110 residing on a client 104. Thus,browser application 110 is one means for accessing a website.

In one embodiment, when a client 104 desires to access the website, theclient 104 initiates a browser application 110 located on client 104.The client 104 typically inputs a Universal Resource Locator (URL) in anaddress field that tells the client 104 which server 102 to contact andwhere to find the corresponding web application 106 located on theserver 102. Browser application 110 can then make Hypertext TransferProtocol (HTTP) requests to server 102 to access a web document. The webdocument returned by the server 102 typically includes links allowingbrowser application 110 to request other web documents relating to thesame or other web application 106.

Client 104 may also include a browser cache 112 that stores webdocuments for web application 106 so that when the user selects aparticular web document to view, the browser application 110 accessesthe web document from browser cache 112 instead of server 102. This canreduce the amount of time for a web document to be displayed and alsothe amount of traffic on the client's network. However, when using abrowser cache 112, the browser application 110 typically defaults to thebrowser cache 112 instead of the server 102. Thus, it is possible for auser to be viewing an old version of a web document instead of the mostrecent version. On the other hand, requesting the web document directlyfrom server 102 every single time a web document is displayed on browserapplication 110 can overload networking connections.

The present invention seeks to overcome these and various deficienciesin web application performance identified above using various novelfeatures which provide more efficient server/client interactions as wellas other functions on client 104. In one embodiment, client 104 includesa local web engine 114 that communicates with an engine cache 116. Aswill be described further below, local web engine 114 is a componentresiding on the client that includes many additional features whichimprove client/server interactions. Local web engine 114 is not specificto any particular web application 106. Engine cache 116 is a datastorage medium separate from browser cache 112. As will be describedfurther below, local web engine 114 controls situations in which browserapplication 110 can access engine cache 116, including allowing enginecache 116 and browser cache 112 to exchange or share information.

In one embodiment, local web engine 114 communicates with localfiles/registry 118. The term “local files” refers to digital contentfiles stored locally at the client 104. As used herein, the term“digital content” refers to any visual or audio content that can bedisplayed or heard. Digital content can be text files, database files,image files, audio files, or movie files, and the like. The term“registry” refers to a place for maintaining information about theclient system such as what hardware is attached, what system optionshave been selected, how computer memory is set up, and what applicationprograms are to be present when the operating system is started. Server102 can also include a registry 108.

While various embodiments of local web engine 114 and local cache 116will be described, generally, in one sense, local web engine 114includes aspects of a local web server in that local web engine 114 canschedule background processes, coordinate the various processes withinthe local web engine, and provide a programming environment that allowsweb-compatible applications to be operated thereon. In this context, thelocal web engine 114 includes a code interpreter module 120 and one ormore application program interfaces (APIs) 122. APIs 122 allow a webapplication to communicate with local web engine 114. It will beappreciated that local web engine 114 may include an API 122 configuredto communicate with various types of digital content—for example, a textapplication API, a database application API, an image application API,and the like. Alternatively, API 122 may represent a universal digitalcontent API where the same API can be used for various types of webapplications or other applications utilizing different digital contents.Thus, local web engine 114 is able to initiate code and also interactwith various types of digital contents.

However, as depicted in FIG. 1A, local web engine 114 providesadditional functionalities beyond what conventional browserapplications, browser cache, and local web servers provide. In theembodiment of FIG. 1A, these features include 1) a control commanddetecting module 124 that can detect control commands embedded in atransmission from server 102; 2) a caching module 126 that stores webapplications, executable code, web documents, security codes, and/orremote files; 3) a local file access module 128 that allows a webapplication or web document, operated from server 102 or client 104, todisplay and use local files; 4) a security module 130 that allows onlyauthorized web applications to access particular local files andprevents other malicious behavior from outside remote sources as well asmaintain secure transactions within the client itself; 5) a networkstatus module 132 that detects the client's offline or online status andadjusts the local web engine 114 accordingly to operate a webapplication offline; and 6) a synchronizing module 134 that synchronizesremote files stored locally with remote files stored at server 102. Inaddition, FIG. 1B illustrates additional features which include 7) apolling module for detecting updates from server 102; 8) a search modulefor performing background searches; as well as other background agentsor modules that can be included in the local web engine 114. Each ofthese features will now be discussed in further detail.

Control Command Detecting Module

In one embodiment of the invention, local web engine 114 improves webapplication performance and offline usage scenarios by allowing server102 to provide client 104 with various different commands to change theclient's behavior. Control commands are generated at the server 102. Forexample, a web application administrator or developer could includecontrol commands in the head of a web document. The control commandscould, for example, appear as special comments or as special javascript.If the client that receives the web document does not have the abilityto detect the embedded control commands, the client ignores the controlcommands and operates the web page as normal. When control commands areidentified by control command detecting module 124, the control commanddetecting module 124 parses the control command and determines thepurpose of the control command. Control commands can be accompanied byadditional code, where the control command indicates how to treat thisadditional code manifest with the control command.

In one embodiment, the control command could be a caching command (seeFIG. 4, reference numeral 149 a) for web application 136, executablecode 138, web document code 140, security codes 142, and/or remote files144 manifest with the caching command. When a caching command isdetected, control command detecting module 124 initiates caching module126 to cache the corresponding code. The cached web application 136,executable code 138, web document 140 and/or security code 142 can besubsequently accessed by the local web engine 114.

Alternatively, the control command could be an execution command toexecute web application 136, executable code 138, web document code 140,and/or security code 142 manifest in the control command, eitherindependently or simultaneous with caching said code. Code interpretermodule 120 executes the web application 136, executable code 138, webdocument 140 and/or security code 142 manifested with the executioncommand.

Additional examples of types of commands will be described herein. Inthis manner, server 102 is able to direct additional client-side actionsto be performed. Optionally, the control command detecting module 124can be configured to strip the control command and/or any code manifestwith the control command from transmissions from server 102.

In one embodiment, detection of control commands is initiated by a useraction. For example, a user may access a web document containing acontrol command. When the web document is received at the client 104,control command detecting module 124 detects embedded control commandstherein. In another embodiment, detection of the control commands isinitiated by the server 102 without a user action. For example, if a newversion of a website is downloaded to a server 102, the server 102 maysend an update message to client 104 with an update command, not shown,to update the browser cache 112 or engine cache 116. In addition to anupdate command, the update message may also include a clear cachecommand, not shown, to clear the browser cache 112 or engine cache 116of old code in favor of the new web application. Of course, the user maybe required to authorize any change to the client 104.

As illustrated in FIG. 1A, engine cache 116 can be configured to storevarious types of data—web application 136, executable code 138, webdocument code 140, security code 142, remote files 144, and the like.Web application 136 may be the same or different than web application106. Web application 136 can be accessed at various times, including,but not limited to, when server 102 and client 104 lose connection. Whena user selects web application 136 to be executed locally from client104, code interpreter module 120 executes the web application 136.

Executable code 138 can be any code configured to perform a particularfunction that may or may not be tied to a web application 106 or 136 orweb document code 140. In one embodiment, executable code 138 is calledby a remote web application 106. An example of this is where theexecutable code 138 provides an alerting function and the remote webapplication 106 initiates the executable code 138 to alert the user ofan event related to web application 106. In another embodiment,executable code 138 is called by a local web application 136. An exampleof this is code that allows a local web application 136 to function whenthe client 104 is offline. In yet another embodiment, executable code138 is called by a process operating on client 104, but not related to aweb application 106 or 136. An example of this is code that alerts theuser of an event detected by a background agent running on local webengine 114.

Web document code 140 can be cached upon the command of server 102. Inanother embodiment, web document code 140 can be cached similar to howbrowser cache 112 stores web documents and accessed by browserapplication 110 for substantially the same reasons. Thus, in oneembodiment, web document code 140 may be transferred or copied fromengine cache 116 to browser cache 112 and vice versa. In anotherembodiment, enough web document code 140 can be cached to provide a userwith enough web pages to navigate a website without requiring that theentire web application 106 be downloaded. This may reduce the amount ofmemory required to store a particular website on client 104. Asdiscussed above, web document code 140 may operate with executable code138 in order to function properly when client 104 is offline.

Security code 142 enable server-driven actions to be secure, preventinga rogue application in the browser application 110 from accessing webapplication 136, executable code 138, web document code 140, securitycode 142, remote files 144, and/or local files 118. For example, thismay be desirable where a web document includes a local file accesscommand (see FIG. 4, reference numeral 1490 to allow a web document toaccess local files. In another example, a source security command (seeFIG. 4, reference numeral 149 c) may be included in the web document toprevent a rogue application from mimicking a valid web application 136,executable code 138, web document code 140, and the like. Securitycommands will be discussed in further detail with regard to securitymodule 130.

Web application 136, executable code 138, web document code 140 and/orsecurity code 142 can exemplarily be separate codes that can bedownloaded at the same or different times. Alternatively, webapplication 136, executable code 138, web document code 140 and/orsecurity code 142 could be part of the same application (see FIG. 1B).

In addition, as illustrated in FIG. 1A, some or all of remote files 108can be downloaded into engine cache 116 and be stored as remote files144. As will be described further below, being able to store at leastsome remote files 144, can assist local web engine 114 in properlyoperating a web application when the client 104 is offline. It will beappreciated that other code and/or files can be stored in engine cache116 to implement functionalities taught herein or other functionalitiesunderstood by those of skill in the art to be within the scope of thisinvention.

Exemplary methods for caching web application 136, executable code 138,web document code 140, security code 142 and/or remote files 144 willnow be described in further detail. FIG. 2 illustrates an exemplarymethod 200 for storing web application 136. At 202, the client 104receives a transmission from server 102. For example, the user accessesa website by displaying a web document which can be, but is not limitedto, a main or home page. Upon receiving the transmission, at 204,control command detecting module 124 analyzes the transmission forcontrol commands. At 206, control command detecting module 124identifies a cache command for the client to download web application136 related to the web application 106. Web application 136 can be thesame code as web application 106 or a modified code. In one embodiment,the web application 136 can actually be embedded in the transmissionmanifest with the cache command. In this case, the caching module 126can parse the web application 136 from the transmission and download theweb application 136 into storage.

Usually, however, the web application 136 is quite large and so, inanother embodiment, the caching command can manifest a pathfile at whicha downloadable version of the web application 136 is located on server102 or another server. At 208, caching module 126 requests theidentified web application 136 located at the identified pathfile. At210, server 102 complies with the request for downloading code andcaching module 126 stores the web application 136 in storage. At 212,control command detecting module 124 can strip the cache command andassociated pathfile and/or web application code from the transmission.If the transmission is a web document, the local web engine 114 sendsthe web document to browser application 110 for display. At 214, browserapplication 110 can generate subsequent web documents related to the webapplication 106 directly from the local web application 136. In oneembodiment, all subsequent requests from browser application 110 can beredirected to web application 136 stored in engine cache 116. In anotherembodiment, redirecting requests from browser application 110 to webapplication 136 can occur only when the client 104 loses communicationwith server 102.

FIG. 3 depicts an exemplary method 300 for implementing a prefetchcaching command and a user security command, thus illustrating thesituation in which multiple control commands may be used simultaneouslyand/or codependently. At 302, client 104 receives a transmission fromserver 102, for example, a web document such as a home page. Uponreceiving the transmission, at 304, control command detecting module 124analyzes the transmission for embedded control commands. At 306, thecontrol command embedded in the transmission is a prefetching commandmanifesting web document code 140 to be prefetched. It will beappreciated that the transmission can directly provide the web documentcode to be cached. Alternatively, the transmission can provide apathfile from which to request a download of a web page. At 308, cachingmodule 126 stores the web document code 140 manifest with the prefetchcommand.

Prefetching has been conventionally used to download web documents inadvance of viewing those web documents. Conventional prefetching schemeshave been limited to downloading only static content such as text andimages. However, increasingly, more web documents and web applicationsare becoming reliant on user input, user authentication, geography, timeof day, previous pages viewed by the user, and other dynamicallychanging information. The present invention provides the ability toprefetch web pages that can include dynamic content that may be viewableonly upon certain actions.

Thus, at 310, the embedded control command also includes a user securitycommand to cache user security code manifest with the user securitycommand. The user security code allows a browser application 110 toaccess the web pages manifest in the prefetch cache command only if auser successfully authenticates herself. At 312, caching module 126stores security code manifest with user security command in engine cache116 for access by security module 130.

At 314, the control command detecting module 124 strips both theprefetch cache command and the user security command from the webdocument and also strips the cached code manifest with each controlcommand. Where the transmission is a web document, local web engine 114sends the web document to the browser application to be displayed to theuser. At 316, the code interpreter module 120 executes the security code142 in engine cache 116 wherein security module 130 monitor for when theuser successfully completes the authentication process. At 318, once theuser is authenticated, the security module 130, using the security code142 stored in engine cache 116, allows the browser application 110access to the prefetched web documents 140 in engine cache 116.

Conventionally, when a user goes to access private information, such asemail, via a web document, the user is normally required to authenticateherself. This may include using a signon and password. Onceauthenticated, the web application normally loads the Web pages thatallows the user to view her private information. However, waiting untilafter the user has performed the authentication process to download thedesired web page can delay the time in which the user is able to accessher private information. In the present invention, simultaneous with oreven before a user performs an authentication process (e.g., logs in),the web pages holding the user's private information is being stored inengine cache 116. Thus the prefetching function described in theforegoing exemplary method 300 reduces the amount of time for a user toview a web page.

It will be appreciated by those of skill in the art that the exemplaryprocesses described above with regard to FIG. 2 and FIG. 3 are providedby way of illustration and not by way of limitation and that processelements, steps and/or actions can be rearranged in order, combinedand/or eliminated and that other actions may be added due to designconsiderations depending on the desired functionality that the server102 will communicate to client 104.

For example, in much the same way that local web engine 114 stores bothweb document code 140 and security code 142 which can operate togetherto increase the efficiency and security of web application viewing,local web engine 114 can also cache web application 138, web documentcode 140, executable code 138 and/or remote files 144 related to theoperation of the web application and/or web documents to enable thelocal web engine 114 to run at least a portion of the web applicationeven when offline. As discussed above, in situations where web documentsinclude dynamic content that may rely on communicating with a server 102or other outside computer, unless there are additional instructions tooperate the dynamic web page offline, the web page will not successfullyfunction. To illustrate this example, an electronic messaging webapplication may have a dynamic web page that instructs the browserapplication 110 to send a request to server 102 to check for new mail ona periodic basis (e.g., every 5 minutes). If the server 102 and client104 are properly connected, the server 102 will respond to the requestto check for new mail with any new messages or with no new messages.However, when the server 102 and client 104 are offline or otherwise notcommunicating, the request to check for new messages will return anerror due to the lack of network connection and the user will typicallybe prevented from accessing any data on the web page.

To overcome this situation, dynamic web pages accessed or cached byclient 104 can include caching commands manifesting code relating to howone or more particular web pages are to operate when the client 104 isoffline. So, instead of directing the check for new mail request toserver 102, the request may be redirected to local web engine 114 toaccess executable code 138 which will return a “false,” similar to a “nonew messages” scenario. In this embodiment, the executable code 138would be reserved only for offline scenarios. Thus, it will beappreciated that FIG. 2 or FIG. 3 could be modified to store webapplication 136, executable code 138, and/or web document code 140 foroffline usage.

Finally, it will be appreciated that web documents can include controlcommands that do not necessarily relate to the functioning of webdocuments by a browser application 110. For example, a caching commandcan be embedded in a web document to cache executable code 138 relatingto engine cache 116 behavior. In addition, a caching command can be usedto store remote files 108 locally in engine cache 116 as remote files144. The foregoing discussion of various control commands illustratesthat server 102 can deliver active code to the client 104 which isexecuted outside of the browser application 110.

With reference to FIG. 4, an exemplary transmission 146 is illustratedin which one or more control commands can be included. In oneembodiment, the transmission is a web document having a head 147 and abody 148. In another embodiment, a header, not shown, can be added tothe web document in a data packet structure. As shown in FIG. 4, variouscontrol commands can be included in the transmission 146. Exemplarily,the control commands are embedded in the head 147 of the web document.However, those of skill in the art will recognize that the controlcommands can be in the body 148 or in a header in a data packet as wellas other methods understood to those of skill in the art in view of thedisclosure herein.

Control commands can be represented as a new HTML element. Thus,exemplarily, the user of the element “COMMAND,” in one embodiment,signals the existence of a control command. Those of skill in the artwill appreciate that other methods may be used to signal the existenceof a control command in a transmission 146 from server 102. While someof the control commands will be discussed further below, exemplarily,head 147 includes a cache 149 a, a prefetch command 149 b, a sourcesecurity command 149 c, a user security command 149 d, an executablecommand 149 e, and a local file access command 149 f. Usually, with eachcontrol command, a code or pathfile is manifest therewith to providefurther instructions relating to the particular command. For example,code block 150 provides code that can be parsed and cached according tocache command 149 a. As discussed above, when control command detectingmodule 124 detects cache command 149 a, the module 124 parses thetransmission 146 for additional code manifest with the command 149 a.Thus, the control command detecting module 124 will detect cache code150 and use the instructions manifest therein to perform thecorresponding function at client 104. In contrast to code block 150,prefetch command 149 b includes a pathfile 151 manifest therewith. Thus,instead of getting the code directly from transmission 146, the client104 can request data located at the identified pathfile at server 102.

Source security commands 149 c and user security commands 149 d will bedescribed in more detail below. However, these are also manifest with asource security code 152 and a user security code 163. It will beappreciated that executable code can also be manifest with sourcesecurity commands 149 c and/or user security command 149 d. Executablecommand 149 e provides code 153 which can be immediately executed atclient 104 or cached and later executed. Finally, local file accesscommand 149 f provide local file access code 154 provided therewith thatdefines the types of files that the web application or web documentassociated with the transmission 146 can access on the client 104.

The body 148 of the transmission 146 includes everything else in thetransmission 146. Often, the body 148 includes one or more hyperlinks164.

Caching Module

As discussed above, in one embodiment of the invention, the local webengine 114 can receive instructions to cache web application 136,executable code 138, web document code 140, security code 142 and/orremote files 144. When such control commands are received, local webengine 114 calls caching module 126 to perform the actual cachingfunction. Caching module 126 thus communicates with engine cache 116 tostore the desired item. The caching module 126 may allow local webengine 114 to access various items stored in engine cache 116 to executeone or more items. Further, as discussed above, executable code 138 canbe detected in transmissions from server 102 that relate to cachingbehavior control. For example, executable code 138 may instruct enginecache 116 to create a specific name space for a document or code to becached, define an expiration date for an existing or cached document tobe maintained in engine cache 116, clear a particular name space holdinga particular document, and the like. The update command and clear cachecommand are examples of caching behavior control commands.

In addition, caching module 126 can perform traditional cachingfunctions that can operate in conjunction with browser cache 112. Whilevarious embodiments herein describe the caching function being initiatedor driven by server 102, caching functions can also be client-driven.For example, caching module 126 can be used to cache static web content,such as text and images, while a user is browsing the Internet. In oneembodiment, caching module 126 may have an opportunistic cachingfunction which only stores the most recently accessed web document code140 and/or remote files 144. Caching module 126 may also compress theinformation that is being stored in engine cache 116 or browser cache112. In addition, when a user is downloading a web page, caching module126 may compare a web page being downloaded with a web page currentlystored in engine cache 116 or browser cache 112 to determine if contenthas changed on the downloaded web page. Caching module 126 assembles theunchanged data stored in engine cache 116 or browser cache 112 and thenew data in the downloaded page and allows the browser application 110to display the assembled version for display on the browser interface.

As will be appreciated, caching module 126 can be programmed withvarious functions that can accelerate access of content (e.g.,coordinating caching, delta encoding, and the like), and may in generalinclude smarter caching algorithms to increase the efficiency of webapplication functionality.

Local File Access Module

In another embodiment of the invention, the local web engine 114comprises a local file access module 128 which allows a web applicationto access local files 118 at client 104. Conventionally, users have beenunable to access local files through a web application except whenuploading or downloading information to and from the web application.Otherwise, the user is generally limited to working outside of the webapplication to use local files. In some applications where the user isallowed to view local files, it is generally done in a separate userinterface than remote files and requires the user to switch viewsbetween local files and remote files.

Thus, in one embodiment of the invention, a local file access module 128is provided to allow a web application to integrate local files into thesame data structure as remote files. So, from the user perspective, thelocal files are handled the same as remote files and the user cannottell the difference between how local files and remote files areaccessed. This seamless architecture enhances the user experience byextending web application functionality to local files on the user'scomputer. Thus, the user can manipulate or maneuver the local files inthe same manner that the user would be able to for a remote file,merging the web application into a client application.

The local file access module 128 includes, but is not limited to,enabling local file access code that interacts with a web application toallow the web application to access data files locally. The local fileaccess module 128 is generic so that any web application configured toallow this functionality can interact with local file access module 128.Generally, the local file access module 128 detects or calls local fileaccess code within the web application itself or stored elsewhere toalter the path of data retrieval for a browser application 110. Thus,the user can have access to both remote files and local files and canmanipulate or maneuver the local files the same way the user can withremote files.

FIG. 5 illustrates an exemplary method 500 for implementing the localfile access module 128. At 502, client 104 receives a transmission fromserver 102. For example, a user accesses a web page which allows a userto view remote files 108 on server 102 (the web page can be executedremotely or locally). For example, a photo management application maypresent various electronic folders for allowing a user to organizedigital photos based on dates the photo was taken, date the photo wasstored to remote files, title, event and the like. At 504, the controllanguage detecting module 124 monitors the web page for a local fileaccess command (see, e.g., FIG. 4, reference numeral 149 f). When alocal file access command is identified, at 506, local web engine 114calls local file access module 128, which identifies the location oflocal file access code that will allow the web application toincorporate local files into the same graphical user interface in whichthe remote files are displayed. The local file access code may exist inthe web page accessed by the user (see FIG. 4, reference numeral 154),may reside at server 102 or may reside at client 104 as executable code138. At 508, code interpreter module 120 executes the local file accesscode.

At 510, the local file access code alters the path of data retrieval forbrowser application 110 to include data stored in local files 118. Thatis, a fetch command for data from the browser application 110 is sent toboth remote files 108 and local files 118 which respond withcorresponding data. For subsequent access by the user for local filesdisplayed in the browser application 110, the local file access module128 instructs the browser application 110 to direct the request to localfiles/registry 118 rather than the server 102.

At 512, the local file access code may also alter the graphical userinterface for the web page. For example, a graphical user interface datastructure for displaying remote files can be altered to additionallydisplay local files. With the local file included in the same datastructure as the remote files, local file access module 128 allows theweb application to apply web-based functionality to local files. Thus,the above example of a web application for photo management andprocessing that has various electronic folders to store remote digitalphotos may now include one or more electronic folders for organizinglocal files.

The user can further be able to use web application functionality onlocal files the same as it would for remote files. For example, whenhandling photo files remotely, the web application may create a smallthumbnail file for the image and make the thumbnail available on a webpage to drag, drop, rearrange, alter the image, and the like. Usinglocal file access code, the web application can perform the samefunctions on local files. Sorting functions can also be applied to bothremote files 108 and local files 118. Utility of the local files in theweb application is independent of whether the user is going to uploadfiles or not to the server 102. Thus, once the local files are includedin this data structure, the local file access module 128 allows the webapplication to handle the local files in much the same manner as itwould for remote files. However, if the user later decides to, forexample, order a print of a local image file, the user would have theoption of uploading the local file to the server 102 for photoprocessing.

It will be appreciated by those of skill in the art that the exemplaryprocesses described above with regard to FIG. 5 are provided by way ofillustration and not by way of limitation and that process elements,steps and/or actions can be rearranged in order, combined and/oreliminated and that other actions may be added due to designconsiderations depending on the desired functionality that the localfile access module 128 is desired to have.

The local file access module 128 is data generic and can allow any webapplications to access local files, upon satisfying certain conditions.For example, the above method can be applied to electronic messaging webapplications. When a user opens a web email application, the usergenerally has various electronic folders for storing electronic messagessuch as inbox, sent, bulk, draft, archived, and the like. With the localfile access module 128, the user may now see one or more folders forlocally stored electronic messages which the user can use or manipulatejust like remotely stored electronic messages.

Another context in which the local file access module 128 becomes usefulis in combining remote and local searches. As will be discussed below, aweb application can be configured to perform remote searches and localsearches by combining a remote search application with a local searchapplication. The local searches can be stored in local files 118. When auser accesses a particular website configured to show remote and localsearches, the website can include executable code on the web page orstored in engine cache 116 that causes the website to access recentsearch requests and/or results—both remote and local. The local searchresults can be combined in the same graphical interface or datastructure as the remote search results.

As can be seen, the local file access module 128 has the potential toallow web applications to access local files in an unrestrained manner.That is, photo processing applications could potentially access othertypes of digital content such as text files, database files, and thelike, that are irrelevant to the web application's functionality. Inaddition, a user may have one or more folders of digital content thatthey do not wish to have accessed by any application with networkfunctionality. Not only does this present security concerns, but it alsohampers the user's ability to find local files that they are trulyinterested in finding. While security measures will be described morefully below with regard to security module 130, in one embodiment,security measures may be implemented to ensure that only authorized webapplications are allowed access to the client's local files. Securitymeasures may additionally be used to limit the type of files and/orlocation of files that a web application can access.

Security Module

In one embodiment, security codes can be implemented at various stepsalong the process for executing a web application on a client 104.First, security codes can be implemented to allow web application 106 or136, executable code 138, and/or web document code 140 to access localweb engine 114. In this sense, a security code can be a marker,indicator or tag that local web engine 114 uses to identify andauthorize an incoming web application, executable code, and/or webdocument as being sent by an authorized third party.

When server 102 sends a web application, executable code, and/or webdocument, a security code (see, e.g., FIG. 4, reference numeral 152) isincorporated into the transmission, which is then sent to client 104.

At client 104, security module 130 detects the security code in theincoming transmission, security module 130 of local web engine 114evaluates the incoming transmission to determine (1) the existence of asecurity code, (2) whether the security code is authentic; and (3)whether the security code is valid. Once a local web engine 114authorizes an incoming web application, executable code, and/or webdocument containing the security code, the authorized web application,executable code, and/or web document is allowed access to local webengine 114 and may be cached in engine cache 116 and/or browser cache112. If no security code is included in the incoming web application,executable code, and/or web document or if the security code isdetermined to be not authentic or invalid, the local web engine 114 mayallow the web application, executable code, and/or web document tointeract with browser application 110 to the extent that, for example, aweb application hosted by server 102 could normally interact withbrowser application 110. However, the unauthorized item will only havelimited access or no access to functionalities provided by local webengine 114.

With reference back to FIG. 4, transmission 146 additionally includessource security command 149 c which instructs the local web engine 114to evaluate the manifest source security code 152 embedded in the head147. The source security command 149 c and source security code 152 aregenerated at server 102. The source security code 152 generally includesa server identifier portion, an authentication portion and a validationportion. It will be appreciated that the same alphanumeric code can beused for one or more purposes. The example of source security code 152in FIG. 4 represents only one way of implementing the security codes andany of a variety of other techniques can be used. Further, it will beappreciated that a source security command 149 c does not necessarilyhave to accompany source security code 152. That is, the mere existenceof source security code 152 may serve as a signal to local web engine114 to initiate security measures.

Exemplarily, the source security code 152 includes a server identifier156, a version indicator 157, a time stamp 158, a uniquifier 159, a usecode 160, an authentication code 161, and the domain identifier 162. Theserver identifier 156 serves to identify the particular server fromwhich the incoming web application, executable code, and/or web documentis sent. The server identifier 156 can be, e.g., the server IP address.The version indicator 157 is typically a one character version indicatorthat indicates the version of the security code. The time stamp 158indicates the time that the security code was generated and can be basedon server's geographic location. The uniquifier 159 is typically anunsigned integer that is unique for each security code generated on aparticular server 102 in the same second. The use code 160 is anencrypted value which identifies the use basis of a particular securitycode, as will be described in further detail below. The authenticationcode 161 is an encrypted value which verifies the source and/orintegrity of the security code, as will be described below. In thisembodiment, the time stamp 158, uniquifier 159 and use code 160 are usedfor validation purposes while the authentication code 161 is used forauthentication purposes. This example illustrates that authenticationportions and validation portions are separate, while in otherembodiments, they may be combined in a single portion of the sourcesecurity code 152.

As discussed above, the source security code 152 includes one or moreauthentication codes 161 for performing one or more authenticationtechnique. Authentication techniques may include, but are not limitedto, checksum algorithms such as, but not limited to, Cyclic RedundancyCheck algorithms, CRC-8, CRC-16, and CRC-32; hashing algorithms such as,but not limited to, MD2, MD4, MD5, and Secure Hashing Algorithm (SHA);digital signature algorithms such as, but not limited to, digitalsignature algorithm (DSA) and digital signature standard (DSS);symmetrical encryption algorithms such as, but not limited to, MessageAuthentication Code (MAC) algorithms, RC2, RC4 and the Data EncryptionStandard (DES); and combinations thereof. Those of skill in the art willappreciate that any authentication method can be used that incorporatesor builds upon any of these methods as well as other authenticationmethods known in the art or that will be developed.

Many of the authentication techniques require knowledge of public keysand/or private keys by either server 102 and/or client 104 to encrypt ordecrypt the authentication code 161 in the source security code 152 aswell as for other uses that may be associated with handling a securitycode, depending on the nature of the encryption. Keys for authenticatingsecurity code 142 may be stored at server 102 in remote files 108 and/orclient 104 in local files 118. In one embodiment, a certificateauthorizing agency can serve as a certificate authorizing source forsharing public keys.

As used herein, “validation” refers to any steps related to ensuringthat the security code is used appropriately. That is, even if thesource security code 152 is authentic, it may not necessarily be valid.Validation portions of source security code 152 allow security codesonly to be valid for a specified period of time or for a single orlimited number of uses. A particular source security code 152 can beconfigured to have a particular usage. For example, a specified securitycode may be generated based on a single-use, multiple-use, or timed-usebasis. Use code 160 contains the information so that the client 104 canascertain the defined usage for each source security code 152. A commoncoding can be used among server 102 and client 104 so that server 102and client 104 will consistently observe the same usage rules. As such,a small coding file may be placed on the remote files 108 and/or localfiles 118 for each server and/or client to reference. However, such acoding file has a minimal footprint and avoids the need for a largertable to be stored for each security code. Further, the client 104 maystore additional information to ascertain whether a security code isvalid. 10771 In one embodiment, validation is based on the time stamp158, uniquifier 159 and use code 160 features of the source securitycode 152 shown in FIG. 4. The time stamp 158 and uniquifier 159 can begenerated using an 11 character base 64 encoding of the time stamp anduniquifier. The use code 160 can be an encrypted alphanumeric code whichsymbolizes a particular use. The use code 160 can be encrypted using anyof the methods described above for authentication codes 161 or any otherencryption method. The validity of security codes that are valid onlyfor a specified period of time can be determined by directly examiningthe content of the security codes. Another option is for certainsecurity codes to be valid under conditions that combine use-based rulesand time-based rules. For example, a security code can be valid for asingle use and for a certain amount of time, meaning that if eithercondition fails, the security code is invalid.

An exemplary process for evaluating source security code 152 in atransmission from server 102 is described in further detail inco-pending U.S. patent application Ser. No. 11/080,240, filed Mar. 15,2005, and entitled “Electronic Message System With Federation of TrustedSenders,” which disclosure is incorporated herein by reference in itsentirety. When a server 102 prepares to send an incoming webapplication, executable code, and/or web document, server 102 generatesthe source security code 152 to be sent with the web application,executable code, and/or web document. Generally, the source securitycode 152 can be placed in any part of the incoming web application,executable code, and/or web document.

When client 104 receives the transmission, security module 130 at theclient 104 analyzes the incoming web application, executable code,and/or web document to determine whether or not it is an authorizedtransmission. The security module 130 determines if incomingtransmission contains a source security code 152 somewhere therewith.The security module 130 authenticates the source security code 152 usingany of the various methods described above for constructingauthentication codes 161. For example, using a private key, the securitymodule 130 could regenerate a checksum and verify that the regeneratedchecksum is the same as the checksum in the source security code 152. Ifthe checksum in the source security code 152 is the same as theregenerated checksum, this indicates that the security code isauthentic, i.e., was generated by the server 102.

If the security code is authentic, the security module 130 determineswhether that particular use of the security code is valid by evaluatinguse code 160. The security module 130 may access local files 118 todetermine if there have been any prior uses of the particular securitycode.

On a similar note, in another embodiment, one way in which security isimplemented is to separate the browser application 110 and browser cache112 from the local web engine 114 and engine cache 116 and allowing onlypermissioned access therebetween. In this manner, any web application136, executable code 138, web document code 140, security code 142,and/or remote files 144 stored in engine cache 116 will not beaccessible to browser application 110 until an event occurs in which thelocal web engine 114 allows access to the stored item in engine cache116. For example, where the user is required to authenticate herselfbefore accessing certain web document code 140 that is stored in enginecache 116, user security code 163 can be provided preventing browserapplication 110 access to these web documents until the security code issatisfied. In this embodiment, user security command 149 d manifests anexemplary user security code 163. User security code 163 is cached andassociated with user signons. User security code 163 can be the samealgorithm that server 102 uses to determine whether a user signon wasauthentic. User security code 163 also directs an authentication requestfrom browser application 110 to local web engine 114 instead of server102.

As discussed above with reference to FIG. 3, allowing access toinformation in engine cache 116 can require storing user security code163 in engine cache 116 and having security module 130 use the usersecurity code 163 to authenticate a user signon. Thus, in oneembodiment, user security code 163 represents executable code containinginstructions on when an application can access certain informationcontained in engine 116.

During offline scenarios, user security code 163 and security module 130can operate to maintain secure access to information stored in enginecache 116 similar to how a server 102 would maintain access to remotefiles 108. For example, when a user is required to authenticate herself,the client 104 and server 102 will normally go through an encryptionand/or decryption process at both ends in order to ensure that the useris legitimate. Similarly, when the client 104 is offline, the local webengine 114 can maintain the algorithms as executable code 138 separatefrom those used to encrypt/decrypt the user input in order to verifythat the user has legitimate access to the information stored in enginecache 116. It will be appreciated that FIG. 6 can be modified to includeredirection of sign on authentication when client 104 is offline.

In another embodiment, a local file access command 149 f manifestinglocal file access code 154 can be implemented to prevent webapplication, web document, and/or executable code from unrestrainedaccess to local files 118. Local file access code 154 stored at enginecache 116 can be used to determine to which digital content or locationsof digital content, to which a web document may have access. The fileaccess code 154 can be detected when the local web engine 114 initiallymakes contact with a website. Alternatively, the file access code 154can be included in a web application request transmitted by browserapplication 110 to the local web engine 114 for local files 118.

In one embodiment, local file access code 154 is an encrypted codesimilar to source security code 152. In this embodiment, common fileaccess codes 154 can be used among different clients 104 so that theserver 102 only has to use one local file access code 154 for aparticular file type or folder. As such, a small coding file may beplaced on the remote files 108 and/or local files 118 for each serverand/or client to reference. The local file access code 154 can beencrypted using any of the methods described above or any otherencryption method. In one embodiment, one of the authentication portions161 or use portions 160 of source security code 152 can also perform thefunction of a local file access code 154. It will thus be appreciatedthat FIG. 3 and/or FIG. 6 can be modified accordingly to include actionspertaining to this embodiment as well.

In view of the foregoing ways that security can be implemented in thepresent invention, security code 142 in FIGS. 1A and 1B arerepresentative of any security code stored in engine cache 116 whetherit be an encrypted code (e.g., source security code 152), authenticationalgorithm (e.g., user security code 163), security condition (e.g.,local file access code 154), and any item related to ensuring thesecurity between server 102 and local web engine 114 and also betweenbrowser application 110 and local web engine 114.

Network Status Module and Synchronizing Module

In another embodiment of the invention, the local web engine 114provides important storage and execution capabilities that allows theweb application to continue running even when the client is offline.Essentially, a web application is able to act like a client applicationwhether it is being executed from server 102 or from client 104 withaccess to both remote files 108 and 144 and local files 118. Because ofthis ability to access remote and local files, the web application canoperate when the client is offline. This provides a seamless transitionbetween online and offline operations.

When the server 102 and client 104 become disconnected, the server 102somehow needs to tell the client how to run various web pages even whenthe client 104 is offline. For those web pages that are dynamicallycreated based on user selections or input. The server 102 needs to beable to instruct client 104 how to generate these pages when the client104 is offline. As discussed above, local web engine 114 can cache webapplications 136 and/or web document code 140. In addition, executablecode 138 can be stored to provide instructions on how to operate webapplication 136 and/or web document code 140 when client 104 is offline.Local web engine 114 can also store remote files 144 in engine cache116.

When network status module 132 detects that the client 104 is offline,the network status module 132 determines which web applications areoperating on the client 104 and begins to utilize web application 136,executable code 138, and/or web document code 140 stored in engine cache116 particular to the web application. Local web engine 114 beginsexecuting these items relating to the web application, allowing the webapplication to continue operating while client 104 is offline. In thismanner, local web engine 114 can basically function as a clone of server102 while client 104 is offline. Because executable code 138 includesinstructions on how to generate or treat web pages when the client 104is offline, web pages can continue to operate as intended. In addition,because remote files 144 are stored locally in engine cache 116, theuser can continue to use and manipulate remote files 144 while client104 is offline. The local web engine 114 thus stores enough of theapplication code to keep the web application running offline.

As discussed above, a local file access module 128 is installed on theclient that allows one or more web applications to access local files118 and handle local files through the web application in the samemanner that a user is able to for remote files 108. When client 104 isoffline, local web engine 114 implements substantially the same processto allow the web application operating on the client 104 to accessremote files 144 and/or local files 118 stored locally. That is,requests from browser application 110 for remote files 108 areredirected to engine cache 116 to access remote files 144. In thismanner, the web application is still able to handle both local files 118and remote files 144 when the client 104 is offline.

The network status module 132 detects when the client 104 reestablishesa connection with server 102. When client 104 is online, the client 104can seamlessly connect back to a network with server 102. When theclient 104 comes back online, the synchronizing module 134 synchronizesthe locally cached remote files 144 with remote files 108.

FIG. 6 illustrates an exemplary method 600 for allowing the client 104to operate a web application when offline. At 602, a user accesses a webdocument either remotely or locally. If the web document is executedlocally the browser application 110 can make requests to server 102 toaccess remote files 108. While the user is accessing the web document orother web documents, at 604, caching module 126 can be storing webapplication 136, executable code 138, web document code 140, securitycode 142 and/or remote files 144 as directed by the accessed webdocument or by other caching protocol (e.g., prefetching mechanisms).Note that the executable code 138 in this embodiment relates to webapplication functionality while offline, although executable code couldalso be cached relating to other functions.

At 606, network status module 132 detects that client 104 is offline. At608, network status module 132 redirects web document requests frombrowser application 110 to locate a web application 136 and/or webdocument code 140 from engine cache 116 instead of from server 102.Generally, engine cache 116 stores all of the necessary web application136 or web document code 140 in order to allow user to viewsubstantially the same content available by having a network connection.

Thus, at 610, network status module 132 redirects data requests frombrowser application 110 to engine cache 116 instead of server 102 inorder to use executable code 138 that provides instructions on how tohandle particular data requests. As mentioned above, engine cache 116stores executable code 138 which can provide additional instructions asto how a particular web document is to be handled in the event of anoffline scenario. The following illustrates this example. In oneembodiment, the web document is a web page through which a user can viewher email messages. The browser application 110 would normally requestdata from remote server 102 for a web document code 140 to bedynamically updated. For example, the web application executes a “checknew messages” request to server 102 to determine if there are newmessages at remote server 102. If the client 104 is online, the datarequest is delivered to server 102, and if there are new messages, theserver 102 responds with update data of whether new messages exist. Inthe prior art, when client 104 is operating offline and a “check newmessages” data request is made, the browser application 110 is stillgoing to try to send the request to server 102. Because the networkconnection does not exist, the request will come back as an error.However, in this invention, network status module 132 causes the datarequest to be redirected to engine cache 116 for executable code 138that instructs the browser application 110, when the “check newmessages” request is made, to return a “false,” instead of an error. Inother words, the inbox folder will not be updated and simply reflect themost recent state of the inbox before the client 104 went offline.

At 612, network status module 132 redirects requests for remote files108 from browser application 110 to locate corresponding remote files144 in engine cache 116. As discussed above, a local file access module128 is installed on the client 104 that allows one or more webapplications to access local files 118 and handle local files throughthe web application in the same manner that a user is able to for remotefiles 108. When client 104 is offline, network status module 132implements substantially the same process to allow the web applicationoperating on the client 104 to access remote files 144 stored locally.That is, browser application 110 requests for remote files 108 areredirected to engine cache 116 to access remote files 144. In thismanner, the web application is still able to handle both local files 118and remote files 144 when the client 104 is offline.

At 614, network status module 132 detects when the client 104reestablishes a connection with server 102. At 616, when client 104comes back online, synchronizing module 134 synchronizes the locallycached remote files 144 with remote files 108. At 618, network statusmodule 132 returns web document, data and remote files requests back tothe browser application 110 default mode.

It will be appreciated by those of skill in the art that the exemplaryprocesses described above with regard to FIG. 6 are provided by way ofillustration and not by way of limitation and that process elements,steps and/or actions can be rearranged in order, combined and/oreliminated and that other actions may be added due to designconsiderations depending on the desired offline scenario functionalityof client 104.

Having discussed in detail the elements of FIG. 1A, it will beappreciated by those of skill in the art that the exemplary embodimentillustrated in FIG. 1A is provided by way of illustration and not by wayof limitation and that modules or components in local web engine 114and/or engine cache 116 can be rearranged in order, combined and/oreliminated and that other modules or components may be added due todesign considerations depending on the desired functionality.

Generic Download Functionality

As discussed above in connection with FIGS. 1A and 4, transmissions fromserver 102 can include executable commands and accompanying executablecode. Alternatively, transmissions from server 102 can includeexecutable commands and links to accompanying executable code.Executable code can be immediately executed at client 104 or cached andexecuted later at client 104. In one embodiment, the executable commandand accompanying executable code (e.g., reference numeral 149 e and code153 in FIG. 4) is a download command.

FIG. 7 illustrates an exemplary method 700, from a client perspective,for downloading files to the client from a server. At 702, a clientsends a request to a web application at the server, where the requestspecifies at least one file to download. At 704, the client receives atransmission from the server. At 706, the client parses the transmissionto identify a download command and an associated download manifest,where the download manifest includes executable code that, when executedon the client, will perform the download of the at least one file to theclient from the server. At 708, in response to identifying the downloadcommand and the associated download manifest, the client executes theexecutable code.

An example of method 700 will now be described in the context of theexemplary network system 100A of FIG. 1A. In this example, at 702, auser at client 104 sends a request to web application 106 at the server102, where the request specifies at least one file to download. Thisrequest can be formulated, for example, when the user accesses at leasta portion of web application 106 through browser application 110. Webapplication 110 in this example can be a web email application which isused to access email over a network. The web email application candisplay to the user a list of all emails and associated email attachmentfiles stored on server 102 that are available for download, and the usercan select the emails and email attachment files that the user wants todownload from this list. The user can then select a button on thedisplay that sends the request to download the selected files. Thisrequest can then be sent to web application 106 by browser application110.

At 704, client 104 receives a transmission from server 102. Thetransmission received at 704 can be a web document such as the exemplarytransmission 146 illustrated in FIG. 4. Alternatively, the transmissioncan be a transmission of data that does not include any web documentcode to be displayed in browser application 110. In this example, thetransmission is a web document that is part of web application 106 thatincludes the control command discussed below, as well as web documentcode that confirms to the user that the download request was receivedand displays the emails and email file attachment files that have beentargeted for download to client 104.

At 706, control command detecting module 124 parses the transmissionreceived at 704 to identify a download command and an associateddownload manifest, where the download manifest includes executable codethat, when executed on client 104, will perform the download of theemails and email attachment files to client 104 from server 102. Asdiscussed above, control command detecting module 124 detects controlcommands in transmissions from server 102. Where a control command isdetected in a transmission, control command detecting module 124 parsesthe control command to determine how to handle the control command.Control command detecting module 124 also detects any code manifest thataccompanies the control command and looks to the control command todetermine how to treat the code manifest. In this case, at 706, afterdetecting an executable download command and an associated downloadmanifest in the transmission of the web document, control commanddetecting module 124 determines that the download command is anexecutable command and that the associated manifest contains code thatshould be executed on client 104.

In one exemplary embodiment, parsing the transmission to identify adownload command and an associated download manifest further comprisesauthenticating the transmission from server 102 as being authorized toprovide download commands to client 104. This authentication can beperformed as described above in connection with security module 130.This authentication assures that unauthorized servers can not providedownloads to client 104.

At 708, in response to identifying the download command and theassociated download manifest, client 104 executes the executable code.During execution of the executable code, the emails and email attachmentfiles designated at 702 are downloaded to client 104 and stored onclient 104. In one exemplary embodiment, a background agent 174 on localweb engine 114 executes the executable code. A background agenttypically performs its functions in the background on client 104, thusmaking the execution of the executable code transparent to a user ofclient 104. Likewise, a background agent can be initiated independent ofa web application, thus enabling the execution of the executable code tocontinue at client 104 even where, prior to the completion of thedownload, browser application 110 is directed to a second webapplication or is terminated. Background agents 174 are described infurther detail with reference to FIG. 1B in co-pending U.S. patentapplication Ser. No. 11/195,284, filed Aug. 2, 2005, which wasincorporated by reference above, and will not be described in detailhere.

Turning now to FIG. 8, an exemplary method 800 is illustrated, from aserver perspective, for downloading files from the server to a client.At 802, a web application at the server receives a request to downloadat least one file. At 804, the server generates a download command andan associated download manifest, where the download manifest includesexecutable code that, when executed on the client, will perform thedownload of the at least one file from the server to the client. At 806,the server sends the download command and associated download manifestin a transmission to the client.

An example of method 800 will now be described in the context of theexemplary network system 100A of FIG. 1A. In this example, at 802,server 102 receives at web application 106 a request to download atleast one file. As with the example described in connection with FIG. 7,the web application in this example is a web email application. Therequest at 802 can be received from a browser application at the client,such as browser application 110 at client 104. The request specifies theemails and email message attachments that the user of client 104 wishesto download to client 104.

At 804, server 102 generates a download command and an associateddownload manifest, where the download manifest includes executable codethat, when executed on client 104, will perform the download of therequested emails and email message attachments from server 102 to client104. At 806, server 102 sends the download command and associateddownload manifest in a transmission to client 104.

In one exemplary embodiment, after server 102 sends the transmission toclient 104, server 102 receives at least one request from a backgroundagent at client 104 to send the requested emails and email messageattachments. In response to the at least one request, server 102 sendsthe requested emails and email message attachments to client 104. The atleast one request to send the requested emails and email messageattachments can be received after the transmission from server 102 isauthenticated as being authorized to provide download commands to client104. The at least one request can also be received from the backgroundagent independently of the operation or termination of browserapplication 110.

Methods 700 and 800 therefore implement a generic download feature whichallows the non-application-specific executable code necessary to performa download to originate at a server and be sent to any number ofclients. Clients can automatically execute the executable code in thebackground even where the browser application through which the originaldownload request was sent is interacting with other web applications orhas been terminated. A user of the browser application can thus accessother web applications or terminate the browser application altogetherbefore the files have finished downloading without affecting thedownload of the requested files.

Generic Upload Functionality

Another type of executable command that can be sent from server 102 toclient 104 is an upload command. FIG. 9 illustrates an exemplary method900, from a client perspective, for uploading files from the client to aserver. At 902, the client sends a request to a web application at theserver, where the request specifies at least one file to upload. At 904,the client receives a transmission from the server. At 906, the clientparses the transmission to identify an upload command and an associatedupload manifest, where the upload manifest includes executable codethat, when executed on the client, will perform the upload of the atleast one file from the client to the server. At 908, in response toidentifying the upload command and the associated upload manifest, theclient executes the executable code.

An example of method 900 will now be described in the context of theexemplary network system 100A of FIG. 1A. In this example, at 902, auser at client 104 sends a request to web application 106 at server 102,where the request specifies at least one file to upload from client 104to server 102. In this example, web application 106 is a photo sharingweb application that allows user to upload their digital photographs tothe web application so that the photographs can be accessed by multipleusers over a network such as the interne. The client can formulate therequest at 902, for example, when at least a portion of the photosharing web application 106 is being accessed by a user through browserapplication 110. Optionally, using the local file access module 128, theuser can access a file dialog of web application 106 that allows theuser to select from a list of all digital photograph files stored onclient 104 that are available for upload, and the user can select thedigital photograph file or files that the user wants to upload from thisfile dialog. The user can then select, for example, a button on a webdocument of photo sharing web application 106 that is configured tosubmit the selected files to photo sharing web application 106. Theclient can then send the request to server 102 by browser application110.

At 904, client 104 receives a transmission from server 102. Thetransmission received at 904 can be a web document such as the exemplarytransmission 146 illustrated in FIG. 4. Alternatively, the transmissioncan be a transmission of data that does not include any web documentcode to be displayed in browser application 110.

At 906, control command detecting module 124 parses the transmissionreceived at 904 to identify an upload command and an associated uploadmanifest, where the upload manifest includes executable code that, whenexecuted on client 104, will perform the upload of the at least one fileto client 104 from server 102. In this case, at 906, after detecting theupload command and the associated upload manifest in the transmission,control command detecting module 124 determines that the upload commandis an executable command and the associated upload manifest containsexecutable code that should be executed on client 104.

In one exemplary embodiment, parsing the transmission to identify anupload command and an associated upload manifest further comprisesauthenticating the transmission from server 102 as being authorized toprovide upload commands to client 104. This authentication can beperformed as described above in connection with security module 130.This authorization assures that files being uploaded from client 104 arenot uploaded to an unauthorized server.

At 908, in response to identifying the upload command and the associatedupload manifest, client 104 executes the executable code. Duringexecution of the executable code, the at least one digital photo filewill be uploaded to server 102 and stored on server 102. In oneexemplary embodiment, a background agent at client 104 performs theexecution of the executable code.

Turning now to FIG. 10, an exemplary method 1000 is illustrated, from aserver perspective, for uploading files to the server from a client. At1002, a web application at the server receives a request to upload atleast one file. At 1004, the server generates an upload command and anassociated upload manifest, where the upload manifest includesexecutable code that, when executed on the client, will perform theupload of the at least one file from the client. At 1006, the serversends the upload command and associated upload manifest in atransmission to the client.

An example of method 1000 will now be described in the context of theexemplary network system 100A of FIG. 1A. In this example, as with theprevious example, web application 106 is a photo sharing webapplication. At 1002, a web application 106 at server 102 receives arequest to upload at least one digital photo file. The request at 1002can be received from a browser application at the client, such asbrowser application 110 at client 104.

At 1004, server 102 generates an upload command and an associated uploadmanifest, where the upload manifest includes executable code that, whenexecuted on client 104, will perform the upload of the at least onedigital photo file from client 104. At 1006, server 102 sends the uploadcommand and associated upload manifest in a transmission to client 104.

In one exemplary embodiment, after the transmission is sent to client104, server 102 receives the at least one digital photo file from abackground agent at client 104. The at least one digital photo file canbe received after the transmission from server 102 is authenticated asbeing authorized to provide upload commands to client 104. The at leastone digital photo file can also be received from the background agenteven where, prior to the completion of the upload, browser application110 is directed to a second web application or is terminated.

Methods 900 and 1000 therefore implement a generic upload feature whichallows the non-application-specific executable code necessary to performan upload to originate at a server and be sent to any number of clients.The executable code can be automatically executed in the background onthe clients and can continue executing even where the browserapplication through which the original upload request was sent isinteracting with other web applications or has been terminated. A userof the browser application can thus access other web applications orterminate the browser application altogether before the files havefinished uploading without affecting the upload of the requested files.

Alternative System Configuration

FIG. 1B illustrates another embodiment of a system 100B for providingserver/client web application interactions. Because the embodiment ofFIG. 1B is described in detail in co-pending U.S. patent applicationSer. No. 11/195,284, filed Aug. 2, 2005, which was incorporated byreference above, FIG. 1B will not be described in detail here.

Intermediary Application

While the present invention has been described in terms of a singleserver 102 and single client 104, multiple servers 102 and multipleclients 104 may implement the teachings of the present invention. Inaddition, an intermediary proxy server may connect multiple clients 104and then communicate with a server 102. In the intermediate proxy serverembodiment, one or more components of local web engine 114 and/or enginecache 116 may reside on the intermediate proxy server which can then beaccessed by one or more clients 104. Each client 104, thus, is notrequired to include the local web engine 114 and/or engine cache 116,but can, in some cases, be serviced completely by the intermediate proxyserver. When the server 102 and intermediate proxy server becomedisconnected, the clients 104 can continue to operate web applicationsby virtue of aspects of local web engine 114 and/or engine cache 116residing on the intermediate proxy server and/or clients 104.

Exemplary Computing Environment

The present invention extends to both methods and systems forclient/server web application configurations. The embodiments of thepresent invention may comprise a special purpose or general-purposecomputer including various computer hardware, as discussed in greaterdetail below. Embodiments within the scope of the present invention alsoinclude computer-readable media for carrying or havingcomputer-executable instructions or executable codes stored thereon.Such computer-readable media can be any available media that can beaccessed by a general purpose or special purpose computer. By way ofexample, and not limitation, such computer-readable media can compriseRAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic diskstorage or other magnetic storage devices, or any other medium which canbe used to carry or store desired program code means in the form ofcomputer-executable instructions or executable codes and which can beaccessed by a general purpose or special purpose computer. Wheninformation is transferred or provided over a network or anothercommunications connection (either hardwired, wireless, or a combinationof hardwired or wireless) to a computer, the computer properly views theconnection as a computer-readable medium. Thus, any such connection isproperly termed a computer-readable medium. Combinations of the aboveshould also be included within the scope of computer-readable media.Computer-executable instructions comprise, for example, instructions anddata which cause a general purpose computer, special purpose computer,or special purpose processing device to perform a certain function orgroup of functions.

The following discussion is intended to provide a brief, generaldescription of a suitable computing environment in which the inventionmay be implemented. Although not required, the invention will bedescribed in the general context of computer-executable instructions,such as program modules, being executed by computers in networkenvironments. Generally, program modules include routines, programs,objects, modules, executable codes, etc. that perform particular tasksor implement particular abstract data types. Computer-executableinstructions, associated executable codes, and program modules representexamples of the program code means for executing steps of the methodsdisclosed herein. The particular sequence of such executableinstructions or associated executable codes represents examples ofcorresponding acts for implementing the functions described in suchsteps.

Those skilled in the art will appreciate that the invention may bepracticed in network computing environments with many types of computersystem configurations, including personal computers, hand-held devices,multi-processor systems, microprocessor-based or programmable consumerelectronics, network PCs, minicomputers, mainframe computers, and thelike. The invention may also be practiced in distributed computingenvironments where tasks are performed by local and remote processingdevices that are linked (either by hardwired links, wireless links, orby a combination of hardwired or wireless links) through acommunications network. In a distributed computing environment, programmodules may be located in both local and remote memory storage devices.

The present invention may be embodied in other specific forms withoutdeparting from its spirit or essential characteristics. The describedembodiments are to be considered in all respects only as illustrativeand not restrictive. The scope of the invention is, therefore, indicatedby the appended claims rather than by the foregoing description. Allchanges which come within the meaning and range of equivalency of theclaims are to be embraced within their scope.

1.-30. (canceled)
 31. A computer-implemented method for downloadingfiles from a server to a client, the method comprising the followingoperations performed by one or more processors: sending, from a browserapplication at the client to the server, a request to download at leastone file; receiving, by the client, a document from the server; parsing,by the client, the document from the server to identify a downloadcommand and executable code; and executing, by a background agentapplication at the client, the executable code to download the at leastone file from the server, the background agent application beingindependent from the browser application.
 32. The computer-implementedmethod of claim 31, wherein the document is a web document.
 33. Thecomputer-implemented method of claim 31, wherein the background agentcontinues downloading the at least one file after the browserapplication at the client is terminated.
 34. The computer-implementedmethod of claim 31, wherein the browser application at the client is aweb email application.
 35. The computer-implemented method of claim 31,wherein the at least one file includes an email message.
 36. Thecomputer-implemented method of claim 31, further includingauthenticating the document from the server as being authorized toprovide download commends to the client.
 37. The computer-implementedmethod of claim 36, wherein the document from the server includes anauthentication code.
 38. A computer-implemented method for downloadingfiles from a server to a client, the method comprising the followingoperations performed by one or more processors: receiving, at the serverfrom the client, a request to download at least one file, the requestbeing sent by a browser application at the client; generating, at theserver, a document to be transmitted to the client, the documentincluding a download command and executable code; and sending, from theserver, the document to the client, wherein, in response to receivingthe document from the server, the client parses the document to identifythe download command and executes the executable code to download the atleast one file from the server by a background agent application at theclient that is independent from the browser application.
 39. Thecomputer-implemented method of claim 38, further including: receiving,from the background agent at the client, at least one request to sendthe at least one file; and in response to the at least one request,sending the at least one file to the client,
 40. Thecomputer-implemented method of claim 38, wherein the at least one fileincludes an email message, and the request to download the at least onefile is received at a web email application at the server.
 41. Acomputer-implemented method for uploading files from a client to aserver, the method comprising the following operations performed by oneor more processors: sending, from a browser application at the client tothe server, a request to upload at least one file; receiving, by theclient, a document from the server; parsing, by the client, the documentfrom the server to identify an upload command and executable code; andexecuting, by a background agent application at the client, theexecutable code to upload the at least one file to the server, thebackground agent application being independent from the browserapplication.
 42. The computer-implemented method of claim 41, whereinthe document is a web document.
 43. The computer-implemented method ofclaim 41, wherein the background agent continues uploading the at leastone file after the browser application at the client is terminated. 44.The computer-implemented method of claim 41, wherein the browserapplication at the client is a web email application.
 45. Thecomputer-implemented method of claim 41, wherein the at least one fileincludes an email message.
 46. The computer-implemented method of claim41, further including authenticating the document from the server asbeing authorized to provide upload commends to the client.
 47. Thecomputer-implemented method of claim 46, wherein the document from theserver includes an authentication code.
 48. A computer-implementedmethod for uploading files from a client to a server, the methodcomprising the following operations performed by one or more processors:receiving, at the server from the client, a request to upload at leastone file, the request being sent by a browser application at the client;generating, at the server, a document to be transmitted to the client,the document including an upload command and executable code; andsending, from the server, the document to the client, wherein, inresponse to receiving the document from the server, the client parsesthe document to identify the upload command and executes the executablecode to upload the at least one file to the server by a background agentapplication at the client that is independent from the browserapplication.
 49. The computer-implemented method of claim 48, furtherincluding: receiving, from the background agent at the client, the atleast one file.
 50. The computer-implemented method of claim 48, whereinthe at least one file includes an email message, and the request toupload the at least one file is received at a web email application atthe server.